\section{Using Events in Highly Distributed Architectures}

Wer heute service-oriented architectures (SOA) einsetzt nutzt dabei immer mehr synchrone request-response Interaktion um remote
Prozesse in verteilten Systemen zu verbinden. Dies ist einerseits gut und fördert die Erzeugung loser Kopplungen auf technischer Ebene, andererseits 
werden enge Kopplungen auf funktionaler Ebene erzeugt. Durch den Wandel im Web, dass solche Dienste immer mehr zu Echtzeitfähigkeit
tendieren wird eine Alternative zu synchronen request-response Verfahren nötig. Event-Driven architecture (EDA) wird als Alternative
dazu gesehen. Sie bietet mehr Agilität mit einer asynchronen Message getriebenen Kommunikation. EDA als Form von SOA ermöglicht einer
natürlichere Anlehnung an das Organisationsmodell.

\subsection{Event-Driven Architecture}

Events sind an sich nicht neues, bekannt sind sie vor allem aus der GUI Entwicklung. Im Umfeld von SOA ist ein Event eine Änderung eines Status. Der
Empfänger eines Event entscheidet über weiteres Vorgehen was zu tun ist oder ob das Event sogar verworfen wird. Das sorgt für geringe Latenzen
und dadurch hohes Reaktionsvermögen. Das Prinzip SOA und EDA ermöglicht somit nahezu Echtzeitfähigkeit.

\subsection{Fundamental Principles}

EDA arbeitet mit einem asynchronen ``Push-Prinzip'' anstatt eines ``Pull-Prinzips''. Das heißt es entsteht keine Blockierung bis eine Antwort ankommt.
Desweiteren werden autonome Nachrichten verwendet, schlanke Nachrichten enthalten dazu eine ``unit of work'' und eine Information
die es dem Empfänger erlaubt die Nachricht identifizieren. Um dies zu erreichen ist ein wohl definiertes Nachrichtenformat nötig.
EDA sorgt dann für Entkopplung und Änderungen können unabhängiger und öfter durchgeführt werden mit minimalen Auswirkungen auf das
Gesamtsystem. Gleichzeitig verschiebt EDA die Verantwortung des Kontrollflusses weg von der Eventquelle hin zum Empfänger.
EDA ist nur dann sinnvoll und wichtig wenn ein Echtzeitverhalten angestrebt wird.

\subsection{Potential Benefits}

EDA sorgt für eine effektive Datenintegration bei gleichzeitiger verringerter Informationsverzögerung. Wie schon erwähnt kann
nahezu Echtzeit erreicht werden. Das System reagiert präziser, soll heißen die Daten verteilen sich zügiger im System. Die Flexibilität
wird erhöht, es ist einfacher möglich Änderungen vorzunehmen. Damit einher geht eine verbesserte Geschäftsagilität und
damit das Ziel von SOA.

\subsection{Aspects of Implementation}

Zur Implementierung müssen die Events normalisiert und klassifiziert werden. Es müssen klare Definitionen von Events erstellt werden um das
Verständnis dafür zu vereinfachen. Die Geschäftsprozesse müssen in diskrete Eventflüsse modelliert werden. Hierbei ist darauf zu achten
wo synchrone request-driven oder asynchrone event-driven Verfahren eingesetzt werden. Die Vermittlungsstellen zwischen den Prozessen tragen 
die Schlüsselfunktionen wie: Kapselung, Abstrahierung, Entkopplung und sehr wichtig die verlässliche Zustellung. Das Thema Sicherheit kann
wie bei SOA abgewickelt werden, es ist sogar möglich Vereinfachungen vorzunehmen aufgrund der hohen Entkopplung.

\subsection{Conclusion}

Event Driven Architecture sorgt für eine weitere Annäherung von IT Systemen an die Umwelt. EDA ist aber nicht
dazu gedacht die existierenden Formen von synchronen request-driven SOA zu ersetzen. Es dient als Zusatz oder als Ergänzung
des bestehenden Systems. Aus technischer Sicht ist es möglich EDA auf einer bestehenden SOA Infrastruktur zu realisieren.
Zusammen ergibt sich für den Anwender dann ein reaktionsfreudiges und hoch konsistentes System.

\subsection{Fazit}

Eine Ereignis gesteuerte Architektur bietet, gegenüber der synchronen Kommunikation, den Vorteil dass eine
Nachricht parallel von mehreren Empfängern abgearbeitet werden kann. Dieses Verhalten kann ein System
beschleunigen bringt aber noch weitere Vorteile wie eine einfachere Entwicklung und Pflege von groß angelegten 
verteilten Anwendungen, Förderung von Komponenten Wiederverwendung und weiteres\cite{javaworld}.
Das EDA keine Neuerfindung ist sagt der Artikel selbst. GUIs verwenden diese Architektur schon
 lange und würden ohne sie nicht gut funktionieren. Man stelle sich 
vor ein Programm würde so lange blockieren bis  alle Dateien vollständig auf die Platte geschrieben worden
 sind bei betätigen der Speichern Taste. Die Frage die offen bleibt ist, warum 
 nicht SOA immer mit EDA kombinieren?

